A2dp连接流程源码分析

在上一篇文章中，我们已经分析了：a2dp初始化流程  这篇文章主要分析a2dp的连接流程，其中还是涉及到一些底层的profile以及protocol，SDP、AVDTP以及L2CAP等。

当蓝牙设备与主机配对完成之后，作为一个BREDR设备，会走SDP的流程进行服务搜索，当服务搜索完成之后，上层应用得到了该设备的相关的服务，将启动相关的profile 的连接流程，如果对方是一个音箱设备，那么就会触发a2dp的连接流程。我们就从开始调用a2dp connect的地方进行分析：

上面的log 的打印是在BluetoothA2dp.java 中，

注：文章中涉及到 Android里面的通信机制，binder之类的机制，限于篇幅，暂时不讲，重点讲 代码的执行流程。

这里的mService 就是A2dpService，其实现在package/app/bluetooth 下面，我们继续看：

下面接着看 消息的处理，这个消息是发往A2dpStateMachine的，最开始是进入到Disconnected的状态机，看看其处理：

这里涉及到JNI的通信，其机制很简单，限于篇幅也不讲解了。其实现在com_android_com_android_bluetooh.cpp中：

 到这里之后，连接的流程就直接进入到协议栈了，这之后就完全是C语言的代码，a2dp的connect 接口实现在btif_av.c里面 ，我们继续看， 

我们继续看 btif_queue_connect 做了什么？从他的注释中，我们看出他是先把建立连接的信息加入到queue中，并且触发queue中的下一次的连接操作。

 把建立连接的事情 transfer到 btif task中，我们继续看：

我们看看btif_queue_connect_next 的实现：

看到上面的代码，我们明白，a2dp的连接执行的函数就是connect_int（bd_addr，UUID_SERVCLASS_AUDIO_SOURCE） ，我们继续分析这个函数：

当前的状态是idle，

 状态改变，最终会上报到JNI层，这里就不分析了。下面我们重点分析BTA_AvOpen 流程，这个BTA_AvOpen 函数名字是不是有点眼熟？在a2dp初始化的流程中，出现的两个函数是BTA_AvEnable和BTA_AvRegister，这里来分析其兄弟函数BTA_AvOpen，

发送BTA_AV_API_OPEN_EVT 时间到btu task.继续分析：

根据我们之前的分析，这个event是在bta_av_ssm_execute 里面处理的：

发现其处理思路都是差不多，先去查阅状态转换表，然后去执行，当前的stream state machine 的状态是bta_av_sst_init 

发现其执行的动作是BTA_AV_DO_DISC，下一个状态是BTA_AV_OPENING_SST，执行的函数是bta_av_do_disc_a2d，发现现在做的操作是先搜索，我们看看其具体的实现：

上面的流程很简单，就是进行 sink service的搜索，　　其实搜索的att list如下：

我们继续看搜索服务的实现流程：

 关于SDP_ServiceSearchAttributeRequest 这个函数在sdp 服务搜索流程 中已经详细讲过，这里不再详细讲解，搜索完成之后执行回调函数a2d_sdp_cback，我们看其实现：

此函数就是处理 搜索的结果，然后再次调用bta_av_a2d_sdp_cback来上报结果，我们继续分析这个回调函数，：

这里发现是向BTU 线程发送BTA_AV_SDP_DISC_OK_EVT 事件，那说明还不是直接在这个回调函数里面去处理的，我们继续看BTA_AV_SDP_DISC_OK_EVT 的处理：

根据a2dp 初始化一文中的分析，他应该是由bta_av_ssm_execute 来处理，我们看看具体的处理：

 状态机的处理讨论都是一样的，这里不作细节分析：

发现状态不变，下一个状态还是BTA_AV_OPENING_SST，执行的动作是BTA_AV_CONNECT_REQ，那么看起来是要进行请求连接的操作的流程了，我们继续看：

执行的函数是bta_av_connect_req：

从函数名称，我们可以发现，a2dp的连接其实是建立在AVDTP 的基础之上的，下面执行到AVDTP 层面的连接了，另外这个函数的第三个参数是 用hdi 作为索引的回调函数，在一簇回调函数中，其实现逻辑是相同的，只是处理的pscb是不同的。现在我们看看 AVDT_ConnectReq的实现：

这里我们发现，其做的事情，先分配了 tAVDT_CCB 结构，然后发送AVDT_CCB_API_CONNECT_REQ_EVT 进入到AVDTP的状态机中，现在我们看看其状态机实现：

发现和我们之前遇到的状态机实现的套路是完全一致的，都是先查找对应的状态表，然后设置下一个状态，最后执行状态表中该action 对应的函数。

刚开始的时候AVDT CCB的状态是idle 状态：avdt_ccb_st_idle ：

那么下一个状态是AVDT_CCB_OPENING_ST，这里需要注意的是，涉及的状态机非常多，每一个protocol 都可能会涉及到状态机，不要搞乱。

这里执行的action有两个：AVDT_CCB_SET_CONN和AVDT_CCB_CHAN_OPEN，我们分别看其实现：

继续看channel open 的流程：

我们知道channel 是建立于l2cap，那么打开channel，就会建立l2cap 通道。我们继续分析：

这里的逻辑其实很简单，就是基于l2cap 建立AVDTP的通道，在AVDTP register 的时候注册到l2cap的数组函数是  avdt_l2c_appl：

l2cap连接之后，对方回复的处理函数应该是avdt_l2c_connect_cfm_cback：，这个函数就不详细分析了，l2cap channel的连接流程都是先连接，然后配置参数，后续的肯定会执行到L2CA_ConfigReq，我们现在看看配置参数完成之后的流程：

我们继续分析avdt_ad_tc_open_ind，其主要是同住ccb、scb channel open event,我们看代码实现：

这里发现，控制信号是ccb 来处理的，media 数据 是scb 来处理的。我们继续看avdt_ccb_event(p_ccb, AVDT_CCB_LL_OPEN_EVT, (tAVDT_CCB_EVT *)&evt)的处理流程：

传来的事件是AVDT_CCB_LL_OPEN_EVT：

当前的状态是AVDT_CCB_OPENING_ST，

下一个状态是AVDT_CCB_OPEN_ST ， 当前状态需要执行的动作是AVDT_CCB_SND_CMD和AVDT_CCB_LL_OPENED，这里分析发现前者是去执行队列中queue住的命令，那这里不去具体分析了，直接看AVDT_CCB_LL_OPENED的流程：

看这个函数的名字，能猜到是已经open 完成，然后做一系列的上报状态的动作。

参考之前a2dp 初始化的分析发现，这里的回调就是bta_av_stream0_cback,我们继续分析：

BTA_AV_AVDT_CONNECT_EVT

我们继续看bta_av_proc_stream_evt的处理：

/* coverity[var_deref_model] *//* false-positive: bta_av_conn_cback only processes AVDT_CONNECT_IND_EVT and AVDT_DISCONNECT_IND_EVT event * these 2 events always have associated p_data */ if (p_data) { bta_av_conn_cback(handle, bd_addr, event, p_data); } else { APPL_TRACE_ERROR("%s: p_data is null", __func__); } 

 这里做了两件事：

 BTA_AV_AVDT_CONNECT_EVT根据之前分析，处理该event的状态机是bta_av_ssm_execute，这个是stream control block，是和stream 相关的。

当前的状态是opening->bta_av_sst_opening,

这里发现，stream 的下一个状态还是opening，这里需要执行的行为是BTA_AV_DISCOVER_REQ， 执行的函数是bta_av_discover_req，这里就开始了AVDTP signaling的流程了。在分析这个流程之前，我们先看一下上面回调函数做了什么？

 该事件 最终会执行:bta_av_sig_chg主要是在bta_av_cb中分配一个和对端地址相对应的tBTA_AV_LCB结构. 对于bta stream state machine没有影响，略过。

下面我们重点分析AVDTP signaling的流程，bta_av_discover_req：这个流程，在hci log也是有所体现，

大概就是分为discover、get capability、set configuration以及open

下面我们逐步分析这个代码流程：

 搜索的结果会保存到p_Scb_sep_info，下面的代码分析会非常的繁琐，这里分析的意义是为了搞清楚AVDTP是如何用代码的形式呈现出来的。

我们继续看AVDTP状态机的运转：

根据前面的分析，我们已经知道，当前的AVDTP 的channel 的状态已经是打开状态了：AVDT_CCB_OPEN_ST

下一个状态依然是 AVDT_CCB_OPEN_ST，执行的action是AVDT_CCB_SND_DISCOVER_CMD和AVDT_CCB_SND_CMD，

我们来分析一下AVDT_CCB_SND_DISCOVER_CMD，

 这个函数就是 向对方的设备发送一个discovery的请求，对应的hci log中：Signaling Identifier: AVDTP_DISCOVER

这里因为篇幅的原因就不往下 再分析avdt_msg_send_cmd的流程了。

那当对方回应我们的这条数据的时候，会调用到哪个函数呢？这个其实上面已经分析了L2CA_Register这个函数，（当然L2cap 的状态机轮转，我们这里就不分析了），注册的是avdt_l2c_appl，

执行的函数是avdt_l2c_data_ind_cback，这里也是一步步路由，从l2cap 上传上来的event 是AVDTP_CCB_MSG_DISCOVER_RSP_EVT,到 channel control block：

然后执行action：AVDT_CCB_HDL_DISCOVER_RSP，下一个状态依然不变，都是打开状态，我们继续看其实现：avdt_ccb_hdl_discover_rsp：

p_ccb->proc_cback其实就是之前 进行AVDT_DiscoverReq传入的参数bta_av_stream0_cback（这里假定就是bta_av_stream0_cback），

发现执行的真正的函数是bta_av_proc_stream_evt，并且最后一个参数是 index，这样封装有什么好处呢？我能想到的是 使得代码的层次感很强，可读性很好。

 我们继续分析：

发送的event 是 AVDT_DISCOVER_CFM_EVT，这里发现最后的回调bta_av_conn_cback是不处理 这个event 的，我们直接看看发送msg 到btu task的情况。

 发送到btu 的event ，最终路由到bta_av_hdl_event 来统一处理，这里根据不同的event ，也是路由到不同的处理函数，当前的0x1216 是通过bta_av_ssm_execute  来处理：

当前的状态是bta_av_sst_opening，

下一个状态依然是BTA_AV_OPENING_SST，执行的action 是BTA_AV_DISC_RESULTS，那么看来是要对discovery 的结果进行处理， 

 从这里，我们意识到 代码的流程在处理 discovery 的resp的时候，当拿到对端 端子的数据的时候，就开始 对各个端子进行 获取能力。

下面我们看bta_av_next_getcap的流程：其对应到hci 的log，如下：

我们 进一步分析：

 这里注意获取cap的最后一个参数和 discovery 的最后一个参数一样，其本质都是bta_av_stream0_cback回调函数。我们继续分析：

这里函数的注释写的非常清楚，就不多加介绍了。最终会执行avdt_ccb_event 进入到AVDTP的状态机中，当函数返回的时候，这部分的流程和discovery的流程非常的相似，只是执行的具体的函数不一样，当get cap的函数返回的时候，会有

 MSG_GETCAP_RSP_EVT 的返回，

这里讨论都类似，我们看看 AVDT_CCB_HDL_GETCAP_RSP 执行的动作：avdt_ccb_hdl_getcap_rsp

我们继续看：

想想discovery 的流程是如何处理的？这里也是类似的，

看看对于这个事件的处理，肯定也是处理get cap的results：

我们看看 对于这个event的处理：

从上面的hci log，我们应该可以猜测到，这个函数里面处理了 get cap的结果之后，肯定是要进行set configuration 的动作：

我们发现上面代码流程直接走了 AVDTP open的流程，为什么没有去set configuration，我们继续看：

我们发现是在open 里面实现的：，这里需要注意，我们前面discovery和get cap 都是 发送给ccb，但是这里开始发送给scb，此时的scb还是idle的状态，

那么scb 的下一个状态依然是idle 状态。 这里执行的action 是AVDT_SCB_SND_SETCONFIG_REQ，我们具体看看：

 这里执行的函数 是avdt_scb_snd_setconfig_req：我们继续分析下这个函数：

分析到avdt_msg_send_cmd，我们这里就不往下继续分析了，后续对端收到set configuration的消息之后会回复我们。

现在我们看下avdt_ccb_event(p_scb->p_ccb, AVDT_CCB_UL_OPEN_EVT, NULL);做的事情，按照之前的逻辑，stream channel open的操作应该是在set configuration rsp 里面执行，我们看看是不是这样：

 我们发现，其action 都是ignore，所以什么也没干，状态还是AVDT_CCB_OPEN_ST

下面我们继续分析，set configuration 之后的rsp 的处理：

找到对应的channel:

我们当前是signal 信号:执行avdt_msg_ind 函数:

我们分别看avdt_scb_event(p_scb,AVDT_SCB_MSG_SETCONFIG_RSP_EVT , (tAVDT_SCB_EVT *) &msg)和avdt_ccb_event(p_ccb, AVDT_CCB_RCVRSP_EVT, NULL);,后者没有做影响流程的操作,执行的action是AVDT_CCB_FREE_CMD和AVDT_CCB_SND_CMD,这里不详细分析了.

上面是次流程打印的log:

scb的下一个状态是AVDT_SCB_CONF_ST

执行的action 是AVDT_SCB_HDL_SETCONFIG_RSP,我们看看 该函数做了什么?按照预期应该会去保存config的结果以及 执行 scb open的操作:

符合我们的预期,下一步进入到 对于scb 的open 的操作中:

我们继续看:

scb的下一个状态 依然是AVDT_SCB_CONF_ST,执行的action 是AVDT_SCB_SND_OPEN_REQ,:

开始 向对端发送 scb open的请求,我们现在分析一下,对方的response:

此时对方传过来的event是AVDT_SCB_MSG_OPEN_RSP_EVT,

上面的重点 就是avdt_scb_event(p_scb,AVDT_SCB_MSG_OPEN_RSP_EVT, (tAVDT_SCB_EVT *) &msg);

现在发现,scb的下一个状态发生了变化,AVDT_SCB_OPENING_ST,而执行的动作也是处理这个resp:AVDT_SCB_HDL_OPEN_RSP:

我们发现 开始 media channel的相关的工作,继续看:

avdtp signaling 的流程走完了,最后是建立media channel.建立l2cap的通道.

在hci log中,也能找到该流程的痕迹:

 到这里,avdtp的流程似乎已经讲完了,因为基本的流程都已经走完了,但是这里要注意一下,我们上面的scb 状态机的状态还是opening 的状态,BTA层的Stream state machine也是处于opening 的状态,而btif_AV的状态机也还处于opening状态.那什么时候会变成open 状态,我们需要继续分析:

上面 建立l2cap的media channel之后(其实也就是stream channel)之后.会进行config,config的response 的处理函数是:avdt_l2c_config_cfm_cback:

我们继续看avdt_ad_tc_open_ind的流程:,这个函数之前已经提到过,里面有signal 信道和数据通道的不同处理 ,当前的新建的l2cap channel是media channel

我们发现 去最终执行了avdt_scb_event(p_scb, AVDT_SCB_TC_OPEN_EVT, (tAVDT_SCB_EVT *) &open);当前的scb 的状态是opening,我们看看 会发生什么?

我们发现,到此,scb的状态变成了AVDT_SCB_OPEN_ST,我们解开了第一个谜团,下面还有两个,我们继续看看.可以猜想一下, 肯定是将open的信息一层一层往上传,然后逐个变成open状态的.我们继续看.

scb 变成open状态之后,还要 执行action是AVDT_SCB_HDL_TC_OPEN:

上面函数的 注释写的非常的清楚,就是上班open event.上面的回调函数就是 bta_av_stream0_cback,我们继续看看回调函数如何处理的:

我们可以看到.这个回调就是将底层传过来的event转换成BTA层的event,这里被转换成(AVDT_OPEN_CFM_EVT--->BTA_AV_STR_OPEN_OK_EVT)  ,然后  通过bta_sys_sendmsg发送到btu task,而处理这些event 的状态机 正是我们前面提到的BTA ssm ,我们继续看:

通过a2dp 初始化的章节分析,我们知道该event 是由bta_av_ssm_execute  来处理的,此刻的bta ssm 也是处于opening 状态,

这里发现.bta ssm 的状态也变成了BTA_AV_OPEN_SST状态,那么我们的第二个谜团解开,继续看.接下来 他要执行的两个action是BTA_AV_ST_RC_TIMER  BTA_AV_STR_OPENED,从名字上面看看,第二个action应该做了一些上报的事情.

这边追了一下代码发现,前者是做了AVRCP的相关的操作,这里暂时不分析.我们看看BTA_AV_STR_OPENED 做的事情:

那上面的回调是在哪里注册的呢?是在bta_av_api_enable的时候,也就是从btif 层进行av enable的时候 传下来的.就是bte_av_callback,

发现回调还是回到btif 层,

到这里,我们见到了 我们一直关心的btif层面的AV 状态机:,event = BTA_AV_OPEN_EVT

也就是btif_av_state_opening_handler ,我们继续看:

我们分析一下btif_sm_change_state:

新的状态就是BTIF_AV_STATE_OPENED  那到这里, 所有涉及到的状态机都已经是open 状态了.

这里补充一张a2dp 各级状态机的轮转图:

那么关于a2dp profile的连接的流程就分析到这里了.